(12) INTERNATIONAL APPUCATION PUBLISHED UNDER THE PATCNT COOPERATION TREATY (PCT) 



(19) Worid InteDectual Property 
Organization 
International Bureau 

(43) International Publication Date 
5 February 2004 (05.02.2004) 




(10) Internationa] Publication Number 

PCX wo 2004/012415 Al 



(51) International Patent Classification^: H04L 29706, 

12/58, G06F 1/00 

(21) International Application Number: 

PCT/GB2003/003243 

(22) Internatioiial Filing Date: 2 lJuly 2003 (21.07.2003) 



(25) Filing Language: 
(2(9 Publication Language: 



English 
English 



(30) Priority Data: 
0217610^ 
03250672.7 



30 July 2002 (30.07.2002) GB 
3 Febraaiy 2003 (03.02.2003) BP 



(71) Applicant (for all designated States except US)i SECU- 
RITY AND STANDARDS UMTTED [GB/GB] ; Suite A, 
192 Moulsham Street, Chelmsford, Essex CM2 OLG (GB). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only): POPE, Nicholas, 
Henry [GB/GB]; 167 Mountnessing Road, Billericay 
CM12 OEE (GB). ROSS, John, Gordon [GB/GB]; 38 
Quilp Drive, Chdmsfoni CMl 4YA (GB). 



(74) Agents: EXELL, Jonathan et al.; Morley House, 26-30 
Holbom Viaduct, London ECl A 2BP (GB). 

(81) Designated States (national): AE, AG, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN. CO, CR, CU, 
CZ, DE, DK, DM, DZ, EC, EE, ES, FI, GB, GD, GE, GH, 
GM. HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, 
LK, LR, LS. LT. LU, LV. MA. MD, MG. MK, MN. MW, 
MX. MZ. NX. NO. NZ. OM, PG, PH. PL. PT. RO, RU, SC, 
SD, SE, SG. SK, SL. SY, TJ, TM. TN. TR, TT. 12. UA, 
UG. US, UZ. VC. VN, YU, ZA. ZM, ZW. 

(84) Designated States (regional): ARIPO patent (GH. GM, 
KE. LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM. ZW), 
Eurasian patent (AM, AZ, BY. KG, KZ, MD, RU, TJ, TM), 
European patent (AT, BE, BG, CH, CY, CZ, DE, DK, EE, 
ES, FI, FR, GB, GR, HU, IE, IT, LU, MC, NL, PT, RO, 
SE, SI, SK, TR), OAPI patent (BF, BJ, CF, CG, CI. CM, 
GA, GN, GQ. GW. ML, MR, NE, SN. TD. TG). 

Published: 

— with international search report 

— before the expiration of the time limit for amending the 
claims and to be republished in the event of receipt of 
amendments 

[ Continue on next page ] 
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(57) Abstract: A sealing method and system based on any data originator authentication mechanism involves an originator (10) 
which represents the entity requiring the data to be sealed and to have itself identified as the originator of the sealed data. The relying 
party (12) is an entity requiring to use the sealed data as proof relating to a transaction. The seal provider (14) is an entity trusted 
to provide seals by the originator and relying parties. The procedure for creating a seal is as follows: the originator (10) creates a 
hash value or other one-way representation of the data to be sealed. The originator (10) then sends the hash value with a seal request 
through a secure channel which authenticates the originator ( 10) to the seal provider (14) and ensures the integrity of the request The 
seal provider (14) then detennines if the authentication of the request is correct and, if so, creates a seal wliich contains an identifier 
for the originator (10), the time of the request, the hash value and a digital signature or other similar mechanism which authenticates 
the data unit as coming from the seal provider (14). The preferred form of digital signature is one using public key cryptography 
such as specified in ITU-T X^09 or Internet RFC 2560. 
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For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations'* appearing at the begin- 
ning of each regular issue of the PCT Gazette. 
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ELECTRONIC SEALING FOR ELECTRONIC TRANSACTIONS 

The present inveation relates to an electronic sealing method and to an electronic 
registration mefliod for use in electronic transactions. 

Existing electronic signature methods are commonly based on use of public/private 
5 • key (asymmetric) cryptography to create a digital signature supported by electronic 
certificates (e.g. as defined in ITU-T X.509). This requires use of certificate status 
methods such as Certificate Revocation Lists (as defined in ITU-T X.509) or on-line 
certificate status checking (as defined in Internet RFC 2560) to ensure the validity of 
certified key (revoked or not) . As the validity of the certified key used to create a digital 
10 signature may change over time, it is often considered necessary to know the time at which 
the signature was created. This can be achieved by applying a secure time-stamp method 
(Litanet RFC 3161, US patent RE 34,954) over the digital signature OSTSI TS 101 733). 

Secure time-stamping methods (ThtOTiet RFC 3 161; US patent RE 34,954) can also 
15 be used on their own (without the digital signature of the originator) to provide integrity of 
transaction data and proof of transaction time. This does not, however, provide any proof 
of the originator. 

These electronic signature methods have two major disadvantages. First, it can be 
20 difficult to gain assurance of the validity of the public key used to verify the digital 

signature (that is the signature verification key). When verifying a signature the relying 
party needs to obtain infotmation on the status of certificate used to validate the signing 
key. This can involve a significant overhead in obtaining the appropriate (revocation) 
status information. It can be particularly difficult, if not impossible, to get this status 
25 information as it applied when the signature was created when there is a significant period 
between the creation of the signature and its verification (as in the case of a subsequent 
dispute over a transaction). 



30 



Secondly, the c^tificate, which relates a name to a signing key, is often created by 
a party which is not directly involved with the business using that certificate. As the 
subject of the certificate is not already 'Tcnown*' to the authority issuing the certificate (the 
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certification authoritjf), there can be difficulty in checking fihie subjects name. This can 
result in significant additional costs and also increases flie probability of errors. 

The present invention seeks to provide an electronic sealing and an electronic 
registration method for use in electronic transactions. 

According to an aspect of the present invention, there is provided a sealing method 
for sealing the details of an electronic transaction including the step of obtaining 
authentication infoimation fi-om an originator, checkmg the validity of that originator's 
auttientication at the time of the transaction and creating a sealed record related to the 
transaction and validity of the originator's authentication informatioiL 

Preferably, the sealed record includes details of the originator of transaction data 
and the time of the transaction and thereby proves the integrity of the transaction data. The 
seal is preferably digitally signed by a trusted seal provider. la the preferred embodiment, 
the transaction data itself is not revealed to the seal provider enhancing its confidentiality. 
The seal may include other information relating to a transaction originator such as a copy 
of originator's public key certified by the seal provider: 

The mefliod advantageously forms an electronic signature having non-repudiation 
properties. The method may use any data originator authentication mechanism or more 
specific form of originator authentication usmg digital signatures based on public key 
cryptography. 

The preferred sealing method overcomes the first disadvantage mentioned above by 
checkmg the validity of originator's authentication information (for example signing key) 
at the time of the transaction. The registration method overcomes the second disadvantage 
mentioned above by involving a party involved in the business functions in the registration 
process. 

According to a preferred embodiment of the present invention. The method includes the 
steps of: 
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the originator digitally signing a transaction data or othier data, 
transmitting the trans action data or other data or a hash value or another 

representation of the transaction, the digital signature and a seal request to the or a seal 

provider, 

providing for the seal provider to determine whether the authentication of the 
request is correct and whether the digital signature is currently vaUd and if so creating a 
seal. 

The seal may contain an identifier for the originator, the time of the request, the 
transaction data or other data, hash value or other one-way representation, by the 
originator, and at least one digital signature or other authentication of the seal as coming 
firom the seal provider. The seal may also contain a digital signature provided by the 
originator which has been checked by the seal provider. 

The originator may be a transaction peer. The sealed record-may include a text 
header and binary data encoded as a teTCt string. 

The method may prefiarably further comprise the step of encoding the transaction 
data or other data and the sealed record, the encoding bemg arranged such that upon 
accessing the encoded data, the sealed record is displayed in a first area of a computer 
interfece and the transaction data or oflier data is displayed in one or more other areas. 

The encoding may comprise MIME and HTML encoding and the areas comprise 

According to another aspect of the present invention, there is provided a computer 
hnplemented transaction method comprising the steps of accepting one or more user inputs 
specifying a transaction, submitting authentication data and data representative of 
transaction data to a system operating the method of any of the preceding claims for 
creating a sealed record, receiving said sealed record and storing said sealed record and at 
least selected parts of said data representative of transaction data or the transaction data. 
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According to another aspect of the present invention, there is provided a system for 
providing a seal for sealing the details of an electronic transaction or data including means 
for obtaining authentication information Scorn an originator, means for checking the 
vahdity of that originator's authentication at the time of seahng and means for creating a- 
sealed record related to the transaction or data and validity of tihe originator's 
authentication information. 

According to another aspect of the present invention, there is provided a transaction 
system arranged to accept one or more user inputs specifying a transaction, submit 
authentication data and data representative of transaction data to a system for creating a 
sealed record as dejBned above, receive said sealed record and store said sealed record and 
at least selected parts of said data representative of transaction data or the transaction data 

Preferably the system further comprises a cUent interface, ttie transaction system 
being arranged to transmit said sealed record and said at least selected parts of said data 
representative of transaction data or the transaction data to the clirat interface. 

Preferably, tiie system further comprises a validation interiSice, the vaKdation 
interface being arranged to accept a user input to validate an existing sealed record, the 
validation inter&ce being operative to transmit said sealed record and said data 
representative of transaction data to a validation system for validating said sealed record, 
said validation system beuig arranged to generate at least part of a sealed record, compare 
it to said sealed record and output a result of said comparison to said validation interfece. 

The system may comprise one or more web pages. 

In one embodiment, an email system may incorporate or interface with a 
transaction system as defined above. The email system may be arranged to receive an 
email message for an intended addressee, submit data fi-om said email or data 
representative of data firom said email to the system to obtain a sealed record, append the 
sealed record to the email message and transmit the email message and appended sealed 
record to the intended addressee. 
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The invention also seeks to provide a sealing method for sealing the details of 
electronic transaction or data including the step of obtaining authentication infoimation 
fiom an originator, obtaining an identification of the originator at the time of sealing and 
5 creating a sealed record related to the transaction or data and validity of the originator's 
identification. 

In the preferred embodiment, a one-way mathematical function of the transaction 
data, and not the data itself, is revealed to the seal provider. This may be used to ensure 
10 that the seal applies to the data in its original form. 

Embodiments of fhe present invention are described below, by way of example 
only, with reference to the accon^)anying drawings, in which: 

15 Figure 1 shows an anbodiment of sealing method using any originator 

authentication mechanism; 

Figure 2a shows an embodimmt of sealing method based on origmator digital 




Figure 2b shows an embodiment of sealing method incorporating a certified copy 
of the originator's public kejr, 

Figure 3 shows an embodiment of seaHng method for email transactions; 

25 

Figure 4 shows an embodiment of sealing method providing a transaction peer; 

Figure 5 shows a modification to the embodimoit of sealing method of Figure 4; 

30 Figure 6 shows an embodiment of sealed registration method and in particular an 

originator set-up stage; 
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Figure 7 shows fhe steps of a routine for creating a sealed registration documoit; 
Figure 8 shows a exanq>le of how a sealed document may be encoded as a text 

string; 

Figure 9 shows a example of how a sealed document n:iay be displayed; and . 

Figure 10 shows the steps of how a trusted agent may be used to validate a seal. 

Referring to Figure 1, there is shown an embodiment of sealing method which is 
based on any data originator authentication mechanism. The scenario depicted in Figure 1 
involves an originator 10 which represents the entity requiring the data to be sealed and to 
have itself identified as the originator of the sealed data. The relying party 12 (of which 
there may be more than one) is an entity requiring to use the sealed data as proof relating to 
a transaction. This may, for example, include the recipient of the transaction data, an 
arbitrator or judge in a dispute or even the origmator. 

The seal provider 14 is an entity trusted to provide seals by the originator and 
relying parties. The seal provider 14 can be a system operated by any suitable 
organisation, such a business specialising in the provision of security services, trade 
organisation or any other suitable organisation. 

In this embodim^ and sc^iario depicted in Figure 1, the procedure for creating a 
seal is as follows. In the first instance, at step 20, the originator 10 creates a hash value 
(for example, flie secure hash algorithm SHAl defined in FTPS 180-1) or other one-way 
representation of the data to be sealed (typically the transaction data). At step 22 tiie 
originator 10 sends the hash value with a seal request through a secure chaimel which 
authenticates the originator 10 to the seal provider 14 and ensures the integrity of the 
request 

At step 24, the seal provider determines if the authentication and integrity of the 
request are correct If so, the seal provider 14 creates a data unit, convenientiy referred to 
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in this description as a seal, which, in this embodiment, contains an identifier for the 
originator 10, the time of the request, the hash value and a digital signature or other similar 
mechanism which authenticates flie data unit as coming from the seal provider 14. The 
preferred form of digital signature is one using public key cryptography such as specified, 
in rrU-T X.509 or Internet RFC 2560. The seal provider 14 may also copy the data 
forming the seal into an audit log file to provide an additional mechanism for assuring the 
validity of the transaction. 

At step 26, the seal is returned to the originator 10. At step 28, the transaction data 
with its seal is passed to each relying party 12, either directly or indirectiy. 

At step 30, any relying party 12 which trusts the sesal provider 14 can verify the seal 
and the integrity of the transaction data to which the seal is ^plied by verifying the digital 
signature in the seal. Thus, the relymg parfy 12 is provided with proof of flie originator of 
flie transaction data, the time of transaction and the integrity of the transaction data. 

Figure 2 shows an embodiment of sealing mettiod which is based on a digital 
signature &om the originator and still provides the scenario of one originator 10, one or 
more relying parties 12 and a seal provide: 14. 

hi this scenario, the prefrared procedure for creating a seal involves the following 
steps. At step 40 tiie originator 10 digitally signs a transaction data and creates a hash 
value or other one-way representation of tiiat transaction data. At step 42 the originator 10 
sends the hash value and the digital signature(s), with a seal request, through a secure 
channel which authenticates the originator 10 to the seal provider 14 and ensures the 
integrity of the request. In this embodiment, the request need not necessarily be 
authenticated If the request is not authenticated, tiie digital signature is used to 
authenticate the originator 10. Other parties may later submit the signed data for sealing 
but the seal with the earliest time can be taken as the one representing the time of the 
original transaction. 
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At step 44 the seal pzovider 14 detenniBes whether the authmtication and integrity 
of the request is correct and also whether the digital signature is currently valid, using the 
signature verification key of the originator 10. If this is the case, the seal provider 14 
creates a data unit called a seal which, in this example, contains: an identifier for the 
5 originator 10, the time of the request, fee hash value, fee digital signature provided by fee 
originator 10, and at least one digital signature or ofeer similar mechanism which 
authenticates fee data unit as coming fiom fee seal provider 14. The seal provider 14 may 
also copy fee data forming fee seal into an audit log file to provide an additional 
mechanism of assuring fee validity of fee transaction. 

10 

At step 46 fee seal is returned to fee originator 10. At stqp 48 fee transaction data 
wife its seal is passed to each relying party 12. 

At step 50, any relying party 12 which trusts fee seal provider 14 can verify fee seal 
15 and fee integrity of fee transaction data to which fee seal is appUed by verifying fee digital 
signature(s) m fee seal. Thus, each relying party 12 is provided wife proof of fee 
originator 10 of fee transaction data, fee tune of transaction, fee integrity of fee transaction 
data and fee validity of fee digital signature which fee originator 10 applied to fee 
transaction data at that given time. In this embodiment, as is depicted in Figure 2a, two 
20 digital signatures may be provided, fee originator's digital signature and fee seal provider's 
digital signature. 

A variation for fee sealing mefeod based on digital signatures^ as shown in Figure 
2b, is one providing a public key that is certified by fee sealing aufeority as being valid at 

25 fee time of fee transaction. In Ibis variation, fee originator 10 includes a request for its 
public key be certified in fee seal request 42b to fee seal provider 14. The seal provider 
checks feat fee origmator*s public key is valid 44b, for example by checking fee validity 
period in fee originator's current X.509 identity certificate and fee revocation status of feat 
certificate. If fee originator's public key is valid feen ftis is included in fee seal certifying 

30 fee vaUdity of fee key at fee time of fee transaction 46b. The originator sends this seal 
along wife fee digital signature to fee relying party 48b. The relying party verifies fee 
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digital signature using the public key^in the seal SOb that the sealing authority certifies as 
being valid at the time of the transaction. 

This form of seal (i.e. one including the public key) maybe used as an alternative a 
public key certificate (such as defined in X.509) with the validity only for a specific 
transaction (i.e. a transaction certificate). Furthermore, a seal may be used as a "qualified 
certificate" meetmg the requirements identified in the European Directive 1999/93/EC on a 
"Community fiamework for electronic signatures" as described in the following table. 



EU Electronic Signature Directive 
1999/93/EC - Annex I Requirement on 
Qualified Certificate Content 


Qualified Seal 


(a) an indication that the certificate 
is issued as a qualified certificate; 


Additional transaction attribute indicating 
that the seal is a form of qualified 
certificate; 


(b) the identification of the 
certification-service-provider and the 
State in which it is established; 


Aheady identified through the Sealing 
Authority certificate. This could be 
repeated as in an additional transaction 
attribute. 


(c) the name of the signatory or a 
pseudonym, which shall be identified 
as such; 


Already included in user name. 


(d) provision for a specific attribute 
of the signatory to be included if 
relevant, dreading on the pinpose for 
which the certificate is intended; 


Additional transaction attribute • 


(e) signature-verification data 
which correspond to signature-creation 
data under the control of the signatory; 


Additional transaction attribute containing 
user public key 
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(f) an indicadon of the beginning 
and end of the period of validity of the 
certificate; 


Validity period is for a single transaction at 
the time ahready given in the time-stamp. 


(g) the identity code of ttie 
certificate; 


Already in time-stamp serial number 


(h) the advanced electronic 
signature of the 

certification-service-provider issuing it; 


Aheady in the time-stamp signature 


(i) limitations on the scope of use 
of tiie certificate, if applicable; and 


Additional transaction attribute 


0) limits on the value of 
transactions for which the certificate 
can be used, if applicable. 


Additional transaction attribute 



This further enhanced seal, which is called h^ein a "qualified seal", has additional 
advantages over an X.509 based certificate in that: 

1) This qualified seal may be used to provide an electronic signature that und^ 
5 the European Directive 1999/93/EC article 5.1 "satisfy the legal requnements of a 

signature in relation to data in electronic fomi in the same maimer as a hand-written 
signature satisfies those requirements in relation to paper-based data". 

2) . A user who already has conventional X.509 certificate, which does not meet 
. the above legal requirematits, can use that certificate to obtain a "qualified seal", which 

10 does meet these reqturemmts. 

3) As the "qualified seal" is valid only for a particular transaction uncertainty 
over the validity of the certificate as the time of the transaction is minimised. 

4) As the "qualified seal" applies to a single transaction the issuing authority 
has much greater control over its liability. 

15 

A variation to the sealing methods described above with respect to Figures 1, 2a 
and 2b is shown in Figure 3 and, in this example, relates to email transaction environmmts. 
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As illustrated in Figure 3, a seal request is passed to the seal provider 14 at s\sp 60, 
which is then to be subsequently forwarded to the recipient(s) 12 identified m the recipient 
list The transaction data is passed to the seal provider 14 together with the seal request 
and then is forwarded, at step 62, with the resulting seal to the identified recipient(s) 12. 

5 

Figure 4 shows anothCT scenario of sealing method for use with transaction peers. 
As illustrated in Figure 4, at step 70 a seal request fi*om the originator 10 is passed throng 
the peer 15 with whom the originator 10 is carrying out the transaction. The seal request is 
passed, at step 72, to the seal provider 14 only if the transaction peer 15 agrees with the 
10 transaction. At step 74 the seal is returned by the seal provider 14 to the transaction peer 
15 and subsequently, at step 76, passed to the originator 10. 

Figure 5 shows anoflier scenario of sealing method for with transaction passing 
through the seal provider. As illustrated in Figure S, at step 80 references to the originator 

IS and transaction data (for example a universal Resource Identifier, see Internet RFC 2396) 
is passed firom the originator 10 to the transaction peer 15. The preferred form of the 
reference to the transaction data is that the reference value is ui^redictable, to avoid 
unauthorised access to the transaction data. The transaction peer 15 then sends these 
references to the seal provider 14 at step 82. The seal provider 14 then requests the 

20 transaction data firom the originator 10 at step 84, which returns with the ti^action data 
tfaroug^i a secure channel which au&enticates the originator 10 at step 86. The seal 
provider 14 then creates the seal which it passes, along with the transaction data, to the 
transaction peer 15 at step 88. The seal may also be sent back to the originator 10, with 
the reference to the transaction data, at step 90. 

25 

The preferred embodiments of seal registration methods provide two forms of 
identification, the first being a security system identifier and the second being a business 
identifier. 

30 The preferred seal registration method is a technique for securely binding a security 

system identifier to a business identifier. 
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The security system identifier is allocated and authenticated by a security system^ 
such as one of the implementations of sealing method described above. When allocated, 
this identifier is unrelated to any "real world" identification but can be used with a security 
system for identification purposes. A security system identifier may, for example, be a 
5 nxunber pair allocated by a seal provider 14 to an originator of sealed data. One number of 
the nimiber pair identifies a community of users, the other number identifies the user 
within the community. The number pair is unique within the set of identifiers allocated by 
the seal provider. 

10 Tlie busmess identifier provides a set of attributes used by the business to identify 

an entity (such as a customs) for the purposes of transacting business therewith.- This may 
include, for example, references used wittiin the business (such as a customer reference 
number) and/or infonnation used to identify the entity more generally (such as the 
customer's name and home address). The busmess identifier is agreed between the subject 

IS and a registration authority. Some attributes may be allocated by the registration authority 
(for exanq)le, customer number), others may be provided by the subject (for example, first 
name, surname and address). The registration would eiflier b? a system operated by or on 
behalf of the business with which the subject is trading, or the registration authority would 
be operated by a third party business whose function is to check infonnation concerning 

20 the user. 

When being set up to use one of the sealing methods described above, a sealed data 
originator 21 is allocated a security system identifier by a seal provider 14, as shown in 
Figure 6. Before aUocatmg a security system to the originator idCTtifier, the seal provider 
25 proves ownership of some means for authentication, hi the embodiment using public key 
techniques this involves proof of possession of a private signing key. 

Having set up two seal origuiators 21 which are to be parties in a business 
transaction, such as a business and its customer, a sealed registration document is created. 
.30 One party (for example the business) acts as a registration authority for the other party (for 
example, the customer). The customer acts as a subject of the registration. Between them, 
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these two parties create a sealed registration document wliich binds the subject identifier to 
the business identifier. 

In the prefCTied embodiment, the sealed registration document is allocated a 
5 document reference (for example a Universal Resource Identifier, see Internet RFC 2396) 
by the registration authority. This registration document ref^-ence can later be used in 
subsequent sealed documents produced by the subject, thereby providing reference to its 
authenticated business identifier. 

10 In the preferred embodiment, the sealed registration document contains: 

(a) the business identifier, 

(b) the registration document reference or some other information that may be 
used to identify the registration for a particular business purpose, 

(c) a seal from the subject which mcludes its security sj^em identifier and 
IS which indicates the subject's agreement that &e business identifier is correct for itself 

(d) a seal from the registration authority which indicates the registration 
authority's agreement that the business identifier is correct for the subject which created 
the seal in stqp (c) above. 

20 An ^bodimentofroutine for creating such a sealed registration document 

between a business acting as the registration authority and a customer acting as a subject of 
the registration is shown in Figure 7. 

The procedure of the example of Figure 7 is as follows. At step 100, the subject 17 
25 and the registration authority 1 9 establish the attributes required for the business identifier 
of the subject 17, such as name, address, customer identifier and so on. 

At step 102, the registration authority 19 allocates the registration a reference (for 
example a Universal Resource Identifier) which is s&at to the subject 17, At step 104, the 
30 subject 17 sends to the registration autiiority 19 a sealed documrait containing the business 
identifia: and the registration document reference. The seal indicates the entity identified 
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with the security system identifier in the seal and agrees ftat fhe busmess identifier is 
applicable to itself. 

. At step 106, if the registration authority 19 has also agreed that the business 
5 identifier is applicable to the subject 17 which sent the sealed document, it will add its own 
seal. This sealed registration document is stored by the registration authority 19 and, if 
required, also passed to the subject 17 for later use in verifying a claim of identity. 

Any sealed document can then include the appropriate registration refermce to 
10 authenticate the identity of the originator. 

The business operating as a registration authority 19 may similarly obtain a sealed 
registration with die seal provider 14 which, in turo, acts as another registration authority 
for the business registration authority. 

15 

It will be ^preciated that the various embodiments described above can be 
combined with one another, as required in any particular implementation of the systems 
described herein. 

20 It will also be appreciated that the embodiments described can provide a method of 

sealing data by a trusted third party to provide independent proof of: the originator, of the 
transaction data, the time of transaction, and the transaction data. The sealing nietfaod 
produces a form of electronic signature, which has hon-repudiation properties and avoids 
the need for certificate revocation or oihsi authentication status checking. The preferred 

25 sealing method builds on costing secure time-stamping methods. 

A method of encoding a seal provides a text string containing a descriptive head^ 
and binary protection data encoded in Base64 as defined in Internet RFC 2045. The header 
includes information on: the identity of the sealing authority, the origmator's identity 
30 (system security identity and business identity) and the time of the transaction. The binary 
protection data includes binary encoding of the sealing authorities digital signature against 
a hash of the transaction data with the originator's identity and the time of the transaction. 
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An example of a text string encoding is giv^ in Figure 8. An alternative encoding is to 
encode ttie data as described above in XML as defined in World Wide Web Consortium 
(W3C) specification Extensible Markup Language (XML) (reference 
http://www.w3.org/TR/REC-xnil). 

5 

A method of encoding the transaction data with the seal uses the encoding defined 
in Internet RFC 2045 to RFC 2049 (commonly called MIME) combined with code for 
viewing hypertext in multiple fimaes such as defined in the World Wide Web Consortium 
(W3C) HTML 4.01 Specification (reference: http://www.w3. org/TR/html4/^ . The seal 
10 itself encoded as described above, is shown, in one firame as a text string, only the header 
need be immediately visible. The sealed document is in the other firame or firames. This 
enables sealed documents, including documents incorporating text, images, voice or video, 
to be viewed through any suitably MIME ejnabled Web Browser. An sample of a sealed 
document is given in Figure 9. 

15 

Referring to Figure 10, an embodiment of routine illustrating how a trusted agent 
may be used to validate a seal is shown. At step 120 the seal provider 14 issues a seal to 
the originator 10, which in turn, at step 122, provides the data and seal to the relying party 
12. At step 124 the relying party 12 forwards the hash of the data together with the seal to 
20 a seal validator 23 which, at step 12S, determines whefiier the seal is valid. At step 126 the 
seal validator 23 returns to the relying party 12 a valid/invalid reply. 

The embodiments described above provide a number of features for the creation of 
a secure seal for subsequent use. First, the seal protects the authenticity of a data such as a 
25 document or transaction. This protection applies to the data both when conomunicated 
between systems and in storage. The seal can be appUed to a hash of data along with the 
time and autiienticated identity of the data origmator. The authenticity is certified using, 
for example, the digital signature of the seal provider. 

30 The ^eal provides long term authenticity of the data and in a form which cannot be 

repudiated, for example by claiming compromise of authentication keys subsequent to the 
seal being appUed. Thus, a seal is provided which establishes the authenticity of the 
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parties and seals the transaction data in a manner which maintains its integrity over time. 
A copy of the seal can be kept by the seal provider in an audit log to provide further proof 
of authenticity. As the seal only contains a hash of the data being sealed, from which the 
original data cannot be re-created, the privacy of the data is maintained. 

The seal can be used by the originator and any other party relying on the 
authenticity of data to validate its authenticity. Any party that trusts the seal provider and 
has a means of authenticating the seal (e.g. using tlie seal providers public key) can verify 
the validity of the seal. The hash value within the seal can be checked against a 
recalculated hash value to check that the seal applies to the given data and that the data has 
been unchanged. Further assurance of the validity of a seal can be achieved by requesting 
a copy of the seal from the seal provider's audit log. 

In this embodiment, once a transaction record and receipt (seal) has been generated, 
as well as the seal to the appropriate party, a copy is saved at the seal provider or at a 
secure location controlled by the seal provider. 

In some embodiments, such as those involving a transaction sequence a seal can be 
applied to each stage of the transaction proving the timing sequence of the transactions. 
For example, in a transaction involving an offer and an acceptance, data relating to the 
offer and also to the acceptance can be each be sealed proving the time relationship 
between the offer and acceptance^ This can, for example, have particular ^plication in 
trading in shares. 

It is also envisaged that in some embodiments the generation of the seal also stores 
data relating to a smgle evmt For example, the event might.be the creation of documents 
or data by an identified originator at a given time. The seal, tiierefore, would provide 
evidence of that event 

Thus, in the preferred embodiments, the seal is issued by a trusted authority (the 
seal provider) which authenticates the document originator, provides proof of time of 
creation of the document linked to a hash code representing the document and is protected 
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by a cryptographic code which proves the authenticity of the seal and which can detect any 
changes in the sealed infoimatioiL The seal, along with the data it authenticates, can be 
sent to any party relying on the authenticity of that data. 

In this regard, a seal can be checked for validity by the relying party or an agent 
trusted by the relying party to validate seals (seal validator). As shown in figure 10, the 
trusted agent can be used to validate a seal simply by forwarding the seal and a 
recalculated hash of the data to that party (124). This can be initiated, for example, by the 
relying party clicking on a button or icon displayed as part of the seal. If the seal validator 
knows and trusts the sealing authority and has the key necessary to verify the 
cryptographic code (e.g. the sealing authority's public key) it can check the validity of the 
seal and confirm that the hash in the seal matches that recalculated by the relying party. If 
the seal is valid and the data hash is the same, the validator would respond by indicating 
that the sealed document provided by the relying party is valid (126). On the other hand, if 
fliere has been any change in the seal, the cryptogr^hic code was not created a trusted 
sealing authority or the hash in the seal does not match the recalculated hash, tide seal 
provider would indicate that that seal has become invalid. 

Thus, the preferred embodiment can provide a seal which is a form of certificate, 
specific to each transaction which incorporates attributes. This seal certifies the user's 
signing key, as well as providing a tune stannp for relating to the transaction or event This 
seal provides a form of certificate which is bound to the transaction, i.e. is transaction 
specific. 

The seals can also be used for voice and video data and indeed can be applied to 
any digitised media such as web pages, video files, audio files, digital photographs and so 
on. Ill the prefOTcd embodiment, the seals are simple to view and verify using, for 
example, an hitemet browsing software. Furthermore, the seals can liable disputes to be 
resolved quickly, saving time and money. It can also protect all parties against denial of 
the existence or content of a document or event and can provide evidence of a transaction 
or data when the information is contested, even years after the event 
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Three variations of the sealing method have been described, one using originator 
authentication, the second adding originator digital signatures, the fbkd adding public keys 
certified to be valid at the time of the transaction. Further variations of the sealing 
methods are envisaged for alternative transaction environments including but not limited to 
5 e-mail, requests passed via transaction peers and transaction data passing through the seal 
provider. 

There is also described a method for registration that applies the sealing method to 
the registration of a business identity between business partners. The registration method 
10 can be used as an altemative to existing electronic certification methods. The registration 
method enables alternative business related registrations to be applied to the same eaiity 
for different business applications. 
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CLAIMS 

1 . A sealing method for sealing the details of an electronic transaction or data 
including flie step of obtaining authentication infonnation from an originator , checking the 
validity of that originator's authentication at the time of seahng and creating a sealed 
record related to the transaction or data and validity of the originator's authentication 
infonnation. 

2. A method according to claun I , wherein the sealed record includes details 
of the originator of the transaction or data and the time of sealmg. 

3. A method according to claim 1 or 2, including the step of digitally signing 
the seal. 

4. A method according to claim 3, wherein the step of digitally signing the seal 
is carried out by a trusted seal provider. 

5. A method according to claim 4, wh^ein the transaction data or oflier data 
itself is not revealed to the seal provider. 

6. A method according to any preceding claim, wherein a resxilt of a one-way 
mathematical function ^lied to the data, is revealed to the seal provider. 

7. A method according to any preceding claim, including the step of storing a * 
copy of the data forming the seal mto an audit log file held remotely from parties to the 
transaction or involved in the data. 

8. A method according to any preceding clann, wherein the seal is passed to a 
relying party directly or indirectly. 
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9. A method according to any preceding claim, including the step of providing 
for checking of a seal, and that it belongs to data which is identical to that to which the seal 
was originally applied, by a relying party or an agent trusted by the relying party. 

10. A method according to any preceding claim, including the steps of: 
the originator digitally signing a transaction data or other data, 
transmitting the transaction data or other data or a hash value or another 

representation of the transaction, the digital signature and a seal request to the or a seal 
provider; 

providing for the seal provider to determine whether the authentication of the 
request is correct and whether the digital signature is cuirently valid and if so creating a 
seal. 

11. Amethod according to claim 10, wherem the seal contains: an identifier for 
the originator, the time of the request, the transaction data or other data, hash value or other 
one-way representation, by the origuiator, and at least one digital signature or other 
authentication of the seal as coming fiom the seal provider* 

12. A method according to claim 1 1, wherein the seal also contains a digital 
signature provided by the originator which has been checked by tiie seal provider. 

13. A method according to any preceding claim, wherein the originator is a 
transaction peer. 

14. A method according to claim 13, wherein the sealed record includes a text 
headCT and binary data encoded as a text string. 

15. A metiiod according to any preceding claim, further comprising the step of 
encoding the transaction data or other data and the sealed record, the encoding being 
arranged such that upon accessing the encoded data, the sealed record is displayed in a first 
area of a computer interface and the transaction data or other data is displayed in one or 
more other areas. 



wo 2004/012415 



PCT/GB2003/003243 



21 

16. A method as claimed in claim 15, wherein the ^coding con^)iises MIME 
and HTML encoding and tiie areas comprise frames. 

5 1 7. A computer implemented transaction method comprising the steps of 

accepting one or more user inputs specifying a transaction, submitting authentication data 
and data representative of transaction data to a system operating the method of any of the 
preceding claims for creating a sealed record, receiving said sealed record and storing said 
sealed record and at least selected parts of said data representative of transaction data or 
10 the transaction data. 

18. A computer program comprising computer program code means for 
performing all of the steps of any of claims 1 to 17 when said program is nm on a 
computer. 

15 

19. A computer program as claimed in claim 18 embodied on a conlputer 
readable medium. 

20. A system for providing a seal for sealing the details of an electronic 
20 transaction or data including means for obtaining authentication information fix)m, an 

originator (10), means for checking the validity of that originator's authentication at the 
time of sealing and means for creating a sealed record related to the transaction or data and 
validity of the originator's authentication information. 

25 21. A transaction systeih arranged to accq)t one or more user ii^mts specifying 

a transaction, submit authentication data and data representative of transaction data to a 
system for creating a sealed record according to claim 20, receive said sealed record and 
store said sealed record and at least selected parts of said data representafive of transaction 
data or the transaction data. 

30 

22. A transaction system according to claim 21, further comprising a client 
interface, the transaction system being arranged to transmit said sealed record and said at 
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least selected parts of said data representative of transaction data or the transaction data to 
the client interface. 

23. A transaction system according to claim 21 or 22, further comprising a 
5 validation interface, the validation interface being arranged to accept a user input to 

validate an existing sealed record, the validation interface being operative to transmit said 
sealed record and said data representative of transaction data to a validation system for 
validating said sealed record, said validation system being arranged to generate at least part 
of a sealed record, compare it to said sealed record and output a result of said comparison 
10 to said validation interface. 

24. A transaction system according to any of claims 21 to 23 comprising one or 
more web pages. 

15 25. An email system including a system according to any of claims 20 to 24, the 

email system being arranged to receive an ^ail message for an intended addressee, submit 
da|a from said email or data representative of data firom said email to the system to obtain a 
sealed record, append the sealed record to the email message and transmit the email 
message and appended sealed record to the intended addressee. 
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